1. Field of the Invention
The present invention relates to the logging of diagnostic information in data processing systems. Specifically, the invention relates to apparatus, methods, and systems for capturing and recording software generated diagnostic traces during execution of complex data processing tasks.
2. Related Art
Among the techniques used in the testing and diagnosis of complex high performance data systems are trace driven diagnostics. Trace driven diagnostics involve the use of diagnostic logs containing information such as significant events that occur in the course of executing programs of interest. The logged information may be used to determine how the system behaves under various conditions and situations.
A trace may contain various levels of information. An address trace, for example, often contains the sequence of memory addresses used to access instructions and operands. An instruction trace typically contains instruction op-codes and register specifiers in addition to the sequence of memory addresses. Other traces may contain only branch instructions or exceptions. Still other traces may contain the contents of registers or semiconductor memory locations. The information in a trace may thus take various forms that capture the sequence in which the events occur.
Several methods for collecting traces are commonly used to facilitate diagnosis and correction of system errors. One method is to use an instruction stepping or trapping feature provided by a processor to expedite software debugging. The instruction stepping feature typically enables the debugging software to gain control after each instruction executed by a program of interest. The debugging software is often set up to write information to a file on the execution of each instruction, thereby collecting a trace of program execution. The EFLAGS TF bit of the X86 architecture implements such a method.
A major disadvantage of instruction stepping methods is that many instructions within the debugging software must be executed for each instruction in the program being traced. In addition, system software typically cannot be traced in this fashion, due to conflicts in the use of system resources between the system software and the debugging software. Traces are typically limited to a specific program and may not reflect the overall behavior of a system in which several programs and multiple system code modules may be running.
A second method of collecting traces is to add instructions to a particular program that generate a trace of certain information as the program executes. By using this information, typically in conjunction with the binary image of the program, a detailed trace of execution may be constructed. The trace generating instructions are typically inserted by a compiler. However, in order to use this method, the user must have access to the source code. Furthermore, only a single program can be traced, which means that related system activity will not be traced.
A third common method of collecting traces is to collect the cycle-by-cycle pin state of a processor as it executes code using a device such as a logic analyzer. This method is often referred to as a ‘bus trace.’ Bus traces can be collected at normal processor speed at least until the capacity of the trace storage device has been reached. Advantages of this method are that it reflects real-time operation and is transparent to the system. Accordingly, the behavior of system code and all active programs can be captured.
Bus tracing has several disadvantages, however, the external hardware required to conduct such traces is often expensive. In addition, for a pipelined processor, the bus activity associated with instruction fetching is asynchronous to the data references that the instructions make, and it can be difficult to link an instruction with a memory reference. Moreover, instructions may be fetched but not actually executed due to the branches contained in the instruction stream. Finally, bus activity reflects physical memory addressing and may be of limited value in situations where virtual addresses are needed.
A fourth tracing method, less commonly used, but possible on microcoded microprocessors, is to modify the microcode of each instruction such that each executed instruction generates an information record that is captured in a memory, or the like, for subsequent analysis. This method typically has much less time overhead than debug software based tracing, and since it operates below the instruction level it is transparent to the system software, thereby enabling the system software to be traced as well. However, this technique can only be used with a writeable microcode memory making it unsuitable for commercial microprocessors which must use higher density read only microcode memory due to space constraints.
The aforementioned diagnostic tracing methods have disadvantages and limitations that reduce the usefulness of conducting tracing on software driven systems-particularly customer owned systems deployed in real world environments. Accordingly, there is a need for a mechanism that permits broader deployment of diagnostic tracing while not possessing the inherent disadvantages set forth above.